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RETRIEVE REGION ID FROM THE NETWORK 
INTERFACE AND ASSIGN TO THE PACKET 



84- 
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IS PACKET ENCRYPTED? 



86- 



)YES 



IF THE PACKET IS ENCRYPTED. RETRIEVE THE VPN 
SECURITY ASSOCIATION FOR THAT PACKET 
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88 -| DECRYPT THE PACKET 

90- 
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REPLACE THE PREVIOUSLY STORED REGION ID FOR 
THAT PACKET WITH THE REGION ID OF THE VPN 



92- 



94 ^ ]YES 

YES 



CHECK THAT THE "ROUTER" FLAG IS SET FOR 
THAT REGION 



102^ ^ 



IF EITHER CONDITION IS NOT MET, THE PACKET IS 
NOT FORWARDED 



LOOK FOR ANY SOCKET LISTENING FOR THE 
INCOMING PACKET 



96 ~f 



98- 



YES 



100^ FORWARD PACKET 

Figure 5 



NO 



CHECK THAT THE DESTINATION IS IN THE SAME NO 
REGION AS THE SOURCE 



LOOK AT SOURCE IP ADDRESS. SOURCE IP PORT, 

DESTINATION ADDRESS, DESTINATION PORT, AND 
CHECK THE REGION ASSOCIATED WITH THE PACKET 
AGAINST THE REGION SPECIFIED IN THE RGNBIND() T,0 
SYSTEM CALL, TO ENSURE THAT SOCKETS RECEIVE 
DATA ORIGINATING ONLY FROM THE CORRECT 
REGION. ARE ALL CONDITIONS MET? 
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SYSTEM AND METHOD FOR tion to and from each of the plurality of network interfaces 

CONTROLLING INTERACTIONS BETWEEN in accordance with the set of policies configured for the one 

NETWORKS of the plurality of regions to which the one of the plurality 

of network interfaces has been assigned. 

FIELD OF THE INVENTION S Another aspect of the invention is a secure server com- 

The present invention relates generally to network ? risi ^ an °F r * in * s y stem kernel J ; a P luralil y of network 

security, and more particularly to a system and method of interfaces which communicate with the operating system 

grouping networks to enforce a security policy. k * rnel i and a ^ al ! <"™P™*6 * plurality of regions 

wherein a set or policies have been configured tor each or 

BACKGROUND OF THE INVENTION 10 the plurality of regions; wherein each of the plurality of 

network interfaces is assigned to only one of the plurality of 

Recent developments in technology have made access regions; wherein at least one of the plurality of network 

easier to publicly available computer networks, such as the interfaces is assigned to a particular region; and wherein 

Internet. Organizations are increasingly turning to external communication to and from each of the plurality of network 

networks such as the Internet to foster communication 15 interfaces is restricted in accordance with the set of policies 

between employees, suppliers and clients. With this configured for the one of the plurality of regions to which the 

increased access comes an increased vulnerability to mali- one of the plurality of network interfaces has been assigned, 

cious activities on the part of both people inside and outside A feature of lhe preseQt invention & the application level 

the organization. Firewalls have become a key tool in approach to security enforcement, wherein type enforcement 

controlling the flow of data between internal networks and 20 ^ ^pal to the operating system. Still another feature is 

these external networks. protection against attacks including intruders into the com- 

A firewall is a system which enforces a security policy on puter system. Yet another feature is a new graphical user 

communication traffic entering and leaving an internal net- interface (GUI) in effective Access Control Language 

work. Firewalls are generally developed on one or more of (ACL). A further feature of the present invention is a visual 

three models: the screening router, the bastion host, and the 25 access control system. Another feature is embedded support 

dual homed gateway. These models are described in U.S. for Virtual Private Networking (VPN). 
Pat. No. 5,623,601 to Vu, issued Apr. 22, 1997 and entitled 

APPARATUS AND METHOD FOR PROVIDING A BRIEF DESCRIPTION OF THE DRAWINGS 

SECURE GATEWAY FOR COMMUNICATION AND FIG . j depicts m implementation of the firewall of the 

DATA EXCHANGES BETWEEN NETWORKS (Vu), 30 present invention 

which is hereby incorporated herein by reference. FIG. la shows a representative computing system pro- 

Vu describes packet filters as a more sophisticated type of tected by a firewall, 

screening that operates on the protocol level. Packet filters FIG. lb depicts another computing system protected by a 

are generally host-based applications which permit certain ^ ^ rewa j[ 

communications over predefined ports. Packet filters may " . t , . JiU - u j^j- 

. . .1 i i j . ,u • - i * FIG. 2 shows the regions and their members as defined in 

have associated rule bases and operate on the principle of resent invention 

that which is not expressly permitted is prohibited. Public C J?I eS !! D . mVeD , „ A „ 

networks such as the Internet operate in TCP/IP protocol. A FIG - 3 15 a graphical representation of ACL commands. 

UNIX operating system running TCP/IP has a capacity of 64 FIG. 4 is a flow diagram for a virus alert. 

K communication ports. It is therefore generally considered FIG. 5 depicts a method by which incoming data packets 

impractical to construct and maintain a comprehensive rule are processed in accordance with the present invention. 

base for a packet filter application. Besides, packet filtering „ m „ 

is implemented using fhe simple Internet Protocol (IP) D ^Su^^^S^S^ 
packet filtering mechanisms which are not regarded as being PREFERRED EMBODIMENTS 
robust enough to permit the implementation of an adequate In the following detailed description of the preferred 
level of protection. The principal drawback of packet filters, embodiments, reference is made to the accompanying draw- 
according to Vu, is that they are executed by the operating ings which form a part hereof, and in which is shown by way 
system kernel and there is a limited capacity at that level to 0 f illustration specific embodiments in which the invention 
perform screening functions. As noted above, protocols may ^ ma y be practiced. It is to be understood that other embodi- 
be piggybacked to either bypass or fool packet filtering men ts may be utilized and structural changes may be made 
mechanisms and may permit skilled intruders to access the without departing from the scope of the present invention, 
private network. PIG i depicts a block diagram showing the relationship 
Accordingly, it is an object of this invention is to provide between a firewall 34 in accordance with this invention, the 
a method for controlling interactions between networks by 55 Internet 36, a Secure Server Network (SSN) 38, a Company 
the use of firewalls with defined regions. Private Net 40, and a Partner Shared Net 42. As shown in 

FIG. 1, communications to and from any other servers or 

SUMMARY OF THE INVENTION networks goes through the firewall 34. 

The present invention is directed to a system and method Two representative firewall-protected computing systems 

of achieving network separation within a computing system 60 are shown in FIGS, la and lb. System 10 in FIG. la 

having a plurality of network interfaces. One aspect of the includes an internal network 12 connected through firewall 

invention is a method comprising the steps of defining a 14 to external network 16. A server 18 and one or more 

plurality of regions; configuring a set of policies for each of workstations 20 are connected to internal network 12 and 

the plurality of regions; assigning each of the plurality of communicate through firewall 14 with servers or worksta- 

network interfaces to only one of the plurality of regions, 65 tions on external network 16. 

wherein at least one of the plurality of network interfaces is System 30 in FIG. lb includes an internal network 32 

assigned to a particular region; and restricting communica- connected through firewall 34 to external network 36. A 
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server 38 and one or more workstations 40 are connected to 
internal network 32. In addition, a server 42 is connected 
through network 44 to firewall 34. Workstations 40 com- 
municate through firewall 34 with servers or workstations on 
external network 36 and with server 42 on network 44. In 
one embodiment network 44 and server 42 are in a sort of 
demilitarized zone (DMZ) providing protected access to 
server 42 to internal users and to external entities. 

In one embodiment, firewalls 14 and 34 implement a 
region-based security system as will be discussed below. 

The operating system on which the firewall 34 is imple- 
mented is the BSDI 3.1 version of UNIX, a security hard- 
ened operating system with each application separated out, 
and protected by type enforcement technology. The func- 
tions of firewall 34 are all integrated with the operating 
system, and each one is completely compartmentalized and 
secured on its own, and then bound by type enforcement 
control. 

Type enforcement, which is implemented within the oper- 
ating system itself, assures a very high level of security by 
dividing the entire firewall into domains and file types. 
Domains are restricted environments for applications, such 
as FTP and Telnet. A domain is set up to handle one kind of 
application only, and that application runs solely in its own 
domain. File types are named groups of files and subdirec- 
tories. A type can include any number of files, but each file 
on the system belongs to only one type. 

There is no concept of a root super-user with overall 
control. Type enforcement is based on the security principle 
of least privilege: any program executing on the system is 
given only the resources and privileges it needs to accom- 
plish its tasks. On the firewall of this invention, type 
enforcement enforces the least privilege concept by control- 
ling all the interactions between domains and file types. 
Domains must have explicit permission to access specific 
file types, communicate with other domains, or access 
system functions. Any attempts to the contrary fail as if the 
files did not exist. The type enforcement policy is 
mandatory, and nothing short of shutting the system down 
and recompiling the type enforcement policy database can 
change it. 

Type enforcement is described in two pending patent 
applications entitled SYSTEM AND METHOD FOR PRO- 
VIDING SECURE INTERNETWORK SERVICES, Ser. 
No. 08/322,078, filed Oct. 12, 1994, and SYSTEM AND 
METHOD FOR ACHIEVING NETWORK SEPARATION, 
Ser. No. 08/599,232, filed Feb. 9, 1996, both of which are 
incorporated herein by reference. Essentially, a type enforce- 
ment scheme provides for the secure transfer of data 
between a workstation connected to a private network and a 
remote computer connected to an unsecured network. A 
secure computer is inserted into the private network to serve 
as the gateway to the unsecured network and a client 
subsystem is added to the workstation in order to control the 
transfer of data from the workstation to the secure computer. 
The secure computer includes a private network interface 
connected to the private network, an unsecured network 
interface connected to the unsecured network, wherein the 
unsecured network interface includes means for encrypting 
data to be transferred from the first workstation to the remote 
computer, a server function for transferring data between the 
private network interface and the unsecured network inter- 
face and a filter function for filtering data transferred 
between the remote computer and the workstation. 

Application-Level Gateway Architecture 

The firewall of the present invention features application- 
level gateways, which negotiate communications and never 



10 



make a direct connection between two different networks. 
Hence, unlike packet filtering, which, as described in the 
prior art, applies rules on every incoming packet of data, the 
firewall applies rules applicable to the network or port in 
which data packets are entering. The gateways have a 
detailed understanding of the networking services they man- 
age. This architecture isolates activity between network 
interfaces by shutting off all direct communication between 
them. Instead, application data is transferred in a sanitized 
form, between the opposite sides of the gateway. 

Attack Protection 

In addition to the firewall's secured type enforced oper- 
ating system and application gateway architecture, the sys- 
tem has been designed to defend against known network 
penetration and denial of service attacks, including: 



20 



25 



30 



35 



SYN Flood attack 
IP spoofing 

ACK storms 

Network probes 

Session hijacking 

SNMF attacks 

ICMP broadcast flooding 

Land attack 

ARP attacks 

Ghost routing attacks 

Sequence number prediction 

Buffer overflows 

Mail exploits 

Authentication race attacks 



45 



50 



55 



60 



65 



Ping of death (fat ping attack) 
Malformed packet attacks (both TCP & 
UDP) 

Forged source address packets 
Packet fragmentation attacks 
Log overflow attacks 
Log manipulation 
Source routed packets 
DNS cache corruption 
Mail spamming 
DNS denial of service 
FTP bounce or poit call attack 
ICMP protocol tunnelling 
VPN key generation attacks 



Intruder Response 

Finding out who and where attacks are originating from is 
a key requirement to taking corrective action. The firewall 
also includes intruder response that allows administrators to 
obtain all the information available about a potential 
intruder. If an attack is detected or an alarm is triggered, the 
intruder response mechanism collects information on the 
attacker, their source, and the route they are using to reach 
the system. 

In addition to real-time response via pager or SNMP, 
alarms can be configured to automatically print results or to 
email them to the designated person. 

Regions 

The growing need for applying specific security policies 
and access requirements to complex organizations requires 
a new way of managing firewalls — regions. Regions are 
groupings of physical interfaces (network cards) and virtual 
networks (VPNs) into entities of similar trust. 

Suppose a company has thousands of roaming users 
connecting to the company network from encrypted virtual 
private network ("VPN") clients — managing such users one 
at a time would be an enormous task. It would be easier to 
organize those roaming users into groups having, as an 
example, full access, medium access, and limited access 
rights. FIG. 2 depicts regions Internet, Secure 'DMZ\ R&D 
Network, Sales OfEces, Worldwide Customer Service, and 
Worldwide Sales. In FIG. 2, all Sales or Customer Support 
departments in the company's offices can be grouped 
together into regions Worldwide Sales and Worldwide Cus- 
tomer Service, respectively. 

Regions permit the grouping of networks and VPNs that 
require the same type of security, thereby eliminating the 
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need to enter multiple versions of the same access rule for an access rule based oo "nodes" of decision criteria. A node 

each network or VPN. Thus regions allow flexibility in can be added to check for such criteria as the time of day, 

tailoring a security policy. In defining regions, the first task whether the connection uses the appropriate authentication 

is to group together networks or VPNs that require the same or encryption, the user or groups initiating the connection 

type of network access. Each network interface card or VPN S request or the IP address or host of the connection. Each 

that is grouped in a region is considered a member of that node is compared against an incoming connection request 

region. A region can consist of the following members: and you determine whether the connection is allowed or 

an interface card, denied based on the results of the node comparison. 

a VPN, Every access rule must consist of two specific nodes. The 

a group of VPNs 10 ^ rst » me Services n °de, decides which service(s) the rule 

, * will control. The second, the From/To node determines the 

an interface card and a VPN, or source region and destination region of the connection. Once 

an interface card and a group of VPNs. m e services and regions for the rule are established, more 

Hence in FIG. 2, userl, user2, user3, mgrl, and mgr2 of nodes can be added to determine specific details about the 

Region named R&D Network would have the same rights 15 connection. 

defined for the R&D Region. In the same way, Roaming r n addition to the Allow or Deny terminal nodes, there are 

Sales 1, Roaming Sales 2, Roaming Sales 3, etc. would have f our otner typcs 0 f nodes you can ad d to an access rule: 

the same rights accorded to all members of Region named decision nodes, filter nodes, redirects or address rewrites, 

Sales Offices. In FIG. 2, userl, user2, Roaming Sales 1, ^ alerts. 

Roaming Sales 2, mgrl, etc., do not necessarily represent 20 

only workstations. In other words, it is possible for user2 to Decision Nodes 

logon the workstation onto which user3 might ordinarily At any point ^ an access mlC) a CODncc tion request can 

logon, or for mgrl to logon the workstation onto which mgr3 5e checked based on the time of dav> its users and groups, 

might ordinarily logon. its ]p addrcsses and hosts or maximum concurrent sessions. 

A n i / * i # 1 t At these decision nodes, the firewall determines whether the 

Access Rules/Access Control Language . ' Tr . 

connection is true or false. If the connection meets the 

A discussion of the use of access control language to criteria listed in the node, the connection is considered true 

define a security policy is explained in greater detail by Reid and proceeds along a "true" branch. If the connection does 

et al. in SYSTEM AND METHOD FOR IMPLEMENTING not meet the node criteria, the connection is considered false 

A SECURITY POLICY, U.S. patent application Ser. No. 30 an d proceeds along a "false" branch. 

09/040,827, filed herewith, which discussion is hereby 

incorporated by reference. Filter Nodes 

Every region is protected from every other region as At any point in an access rule one can check whether a 

defined in the firewall of the present invention. All connec- 3S connection has certain authentication or encryption, use 

tions to and from each region are first examined by the SmartFilter to block particular WWW connections, or filter 

firewall. Regions may communicate with each other only if the connection to see if it contains Java or ActiveX content, 

an appropriate access rule has been defined. For each access Filters differ from decision nodes in that they do not deter- 

rule, first, the services that the rule will control must be m ine whether a connection is true or false. Instead, filters 

defined, then, second, the regions that the connection is 4Q attempt to apply a condition to the connection. If the filter 

traveling between must also be defined. For example, if the can be applied to the connection, the filter is performed and 

Internal region is to be allowed to access Telnet services on the connection proceeds along the same path. If the filter 

the Internet region, the access rule must specify Telnet as the do es not apply to the connection, the filter is ignored and the 

service that the rule controls and specify the From: region as connection still proceeds. 

Internal and the To: region as Internet. Hence, the firewall of 45 

the present invention does not allow traffic to pass directly Redirects or Address Rewrites 

through the firewall in any direction. Region to Region A reW rite node is a point in an access rule where source 

connections are made via an application aware gateway. or destination addresses are mapped to other source or 

Application-level gateways understand and interpret net- destination addresses. Destination IP address rewrites allow 

work protocol and provide increased access control ability. 5Q an inbound connection through network address translation 

The ACLs are the heart and soul of the firewall. For each (NAT) address hiding to be remapped to a destination inside 

connection attempt, the firewall checks the ACLs for per- the NAT barrier. Source address rewrites can be used on 

missions on use and for constraints for the connection. outbound connections to make the source appear to be one 

Constraints can include: encryption requirements, authenti- of many external addresses. This process allows the internal 

cation requirements, time of day restrictions, concurrent 55 hosts to be aliased to external addresses. Rewrites can be 

sessions restrictions, connection redirection, address or host based on any connection criteria, including users, 
name restrictions, user restrictions and so forth. 

Access rules are the way in which the firewall protects 



Alerts 



regions from unauthorized access. For each connection At any point in an access rule, one can add an alert that 
attempt, the firewall checks it against the defined access 60 notifies recipients when a connection has reached a particu- 
rules. The rule that matches the characteristics of the con- lar point in an access rule. Using these alerts, one can 
nection request is used to determine whether the connection monitor specific users, IP addresses and other criteria con- 
should be allowed or denied. tained within a specific access rule. 

With the firewall of the present invention, access rules are 

created in a completely new way — using decision trees. 65 

Knowing that an access rule is based on a series of decisions When a connection request reaches a node in a rule, it is 

made about a connection, the firewall permits the building of checked against the information in the node. If the connec- 



True and False Branches 
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tion is a filter node, the filter condition is either applied or Rewrites can be based on any connection criteria, includ- 

ignored. Only one branch leads out of a filter node. If the i n g users. So the administrator can have anonymous FTP 

node happens to be a decision node, there are two possible connections directed to a public access FTP server on the 

results. If the connection meets the criteria listed, it is Secure Server Net, but remap users to their internal 



considered true and follows the "true" branch of the access 
rule. Otherwise, the connection is considered "false" and 
follows the false branch. 

Referring to FIG. 3, the design for this feature falls almost 



machines. 



User Defined Alerts 



directly out of the GUI representation. The GUI presents ™ ^ ... t . . , 

access rules as a decision tree with special kinds of nodes io The firewall s access control diagrams also include the 

which make true or false decisions. Each decision leads to capability of sending alerts, with an administrator-defined 

a branch which contains more nodes. Along the way, filters message, based on any connection decision. Alerts can be 

can be acquired. These filters are not processed by the kernel dropped into the access flow diagrams at any point. If a 

with the exception of redirects (rewrite destination address connection reaches that point in the diagram, the alert is 

or port). In FIG. 3, the time of day is checked (50). If during 15 triggered. For example, in FIG. 4, a check for viruses is 

business hours, the user is checked (52). Certain users are performed on a file (70). If a virus is found, the administrator 

allowed, so connection is allowed (54) as indicated by the ^ alertcd ( 12 ), and the transfer is redirected to a safe location 

check mark. However, some users (56) require a SmartFilter f 0T j ater mS p ec tion (74). 
check (58), whereas everyone else is denied (60). 

The firewall of the present invention introduces a revo- 20 The ACLs consist of all the required kernel code. This is 

lutionary means to manage network access control. Tradi- all the code that implements the rules themselves in the 

tional firewalls provide lists of access control rules, but as kernel including: build, modifying, deleting, and querying 

more rules and controls are added, these lists become the rules. Also included are the system calls that the user 

unmanageable. As shown in FIG. 3, the present invention i eve i programs need to use the ACLs. The parsing of the 

presents a visual means by which access control can be 25 return values, especially the filters are not part of the ACLs 

defined and easily understood through flowchart style dia- themselves since the filter rules are defined dynamically by 

S rams - the programs issuing the system calls to build the ACLs. It 

The firewall 5 s access flow diagrams allow any decision & tne mtent tnat the kemel be flexible enough to handle all 

criteria to be based on any other decision, in any order. If the 3o the filter requirements without needing modifications for 

administrator wants to check user first, then time, then apply future enhancements 
a specific access policy, they can. In addition, the flow 

diagrams are object oriented for greater power. The ACLs themselves must satisfy the requirements laid 

Access control rules on the firewall can be defined with out b y the GUI design. This dictates to a large degree how 

flexibility previously unknown in the industry. This allows, 35 the rules must be implemented. Since the user has no direct 

for example, for different web filtering polices on a per-user access to the ACLs (rather they use the user interface), there 

basis, the ability to deny a connection if it isn't encrypted, are no ease of use concerns here except to say that the ACLs 

authenticate a connection by strong token and another must be something the developers can work with easily, 

connection by password. Access rules can incorporate any of Hence, there exists a good set of tools to debug the ACLs. 

the following criteria: 4Q 

Source and destination Region Virtual Private Networking 
Users and groups 

Source and destination addresses, networks, hosts, and Virtual Private Networking (VPN) has been embedded 
domains iato the architecture of the firewall of the present invention, 
Type of service (WWW, Email, Telnet, FTP, etc.) ^ making it an operating characteristic of the operating 
Time of day Day of week system, as opposed to other firewalls which added VPN 
Load balancing ^ ater * E verv access control is available to VPN connections 
w , /. ^ in exactly the same way as for physically connected net- 
Maximum number of concurrent sessions t ♦ i -m . • * jj 
n . j . 1 c • works: user controls, IP restrictions, protocol filters, address 
Required eve of encryption 50 hidi muUi . homing> and more . VPN is a method of 
Required level of authentication (strong token, password, authenticating and transparent i y encrypting bi-directional 

e,C J ■ o. ,™ , . ,. -x data transmissions via the Internet. Both gateway to gateway 

Protocol filters (WWW, FTP^ee later in this section) Detwork i inks as well as roaming ^ Qn WN enabled 

SmartFilter™ URL blocking policy (see later in this laptops afe utnizing tbe and CQSt effectiveness of 

section) 55 ypj^ ( nternet encr ypted communications. VPN technology 

Multiple external IP address connected to k embedded in ^ core design 0 f the firewall of the present 

Source and destination service port and IP address invention 
rewrites 

Address and Port Rewrites 60 Proxies 
The firewall's access control diagrams include the capa- 
bility of IP address rewrites, which allows a connection are usually 2 sockets per session, client_sock and 
inbound through NAT address hiding to be remapped to a server__sock. Each socket has two endpoints, so there can be 
destination inside the NAT barrier. Also, rewrites can be tip to four different IP addresses. Note that loc_dst_addr 
used on outbound connections to make the source appear to 65 could be anything, if the firewall bound to a wildcard 
be one of many external addresses. This allows internal address. Here are diagrams for BFS Inbound, BFS 
hosts to be aliased to external addresses. Outbound, and the firewall of the present invention. 
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clicnt_sock scrvcr_sock 

client {cli addr) > [firewall (invention)] > (srv_addr) server 

(loc_dst_addr) (loc_src_addr) 



Proxy Signals 

The SIGWINCH signal is used to force all ACLs to be io 
rechecked and for proxies to re-initialize themselves (for 
proxies that use config files). Most proxies will handle this 
signal themselves, but if secured did an ACL before starting 
a proxy, it must also do the recheck. The SIGWINCH signal 
will come from the backend, which will use killpgO to signal 15 
all the inetd daemons, secured processes, and their child 
proxies or servers. Note that the default action for SIG- 
WINCH is ignore, so inetd did not need to be modified. 

Some transient proxies use the SIGALRM internally to do 
idle proxy timeouts (tcpgsp, tnauthp, sqlp). 2Q 

All proxies should shutdown cleanly if given a SIGTERM 
signal. The backend (daemond actually) uses SIGTERM to 
kill inetd processes when the last service has been removed. 
We have modified inetd to catch SIGTERM and then use 
killpg(SIGTERM, pgid) to kill all its children (proxies and 
secureds). When it starts up, inetd creates a new process 
group and becomes the leader, which allows it to kill all 
children easily. 

Squid will re-open (not rotate) its logfiles if given the 
SIGUSR1 signal, and re-initialize itself if given SIGWINCH 
or SIGHUP. Note that this means squid does not do ACL 
rechecks, it treats itjust like a SIGHUP-— closes its listen 
sockets and waits 30 seconds for active sessions to 
terminate, then re -opens listen sockets. This easy way out 
was chosen because squid's connections are relatively short- 
lived. 35 

Standard Proxy Options 

The following options are passed to secured by the 
backend writing them on the inetd. conf line: 
-D te_dom Set the TE domain of our child process to 40 

te_dom 

-N service_number the service number is required for ACL 
calls. 

secured will pass this number on to all proxies 
-t Specifies that secured is running a transient service (with 45 
the wait flag in inetd .conf). ACL checks are not done by 
secured for transient services, because the service itself 
must do ACL checks, 
-u Specifies that this service supports the notion of a user 
name, so secured should let service perform its own ACL 50 
checks. Currently only FTP, telnet and WWW support 
user names. Note: only needed for ftpp, because tnauthp 
and squid already do their own ACLs. 
The following options are passed to a proxy by the 
backend writing them on the inetd .conf line: 55 
-a audit_jiame use 'name' in call to openlogO and for 
auditing 

-i N specify session idle timeout as N seconds 

-I N specify proxy idle timeout as N seconds (transient only) 

-P ch specify descriptor port, ch=S for secure, ch«L for lpr, 60 

ch-G for generic, otherwise, ch-N specify fixed port, or 

ch=low-high to specify a port range 

The following ACL return values are passed to short-lived 
proxies by secured: 

-N service_number the same service number that secured 65 

got via backend 
-c cli_rgn set cli__region 



-s srv_rgn set srv__region 

-D IP specify the server IP address 

-M IP specify an IP address to spoof as loc_src_addr, for 
MAT-out 

-p N specify the server port number 

-P N specify fixed value for descriptor port 

-C spoof client-side socket (typically outbound proxies) 

-S spoof server-side socket (typically inbound proxies) 

By letting the ACLs control so many settings, the inetd- 
.conf lines are much simpler and the degree of control is 
much greater. For example, here are some BFS inetd.conf 
entries for inbound proxies: 

inbound_udp_relay -e 199.71.190.101 -w 65546 -u 

g_udp_ir -d 192.168.128.138 -m -g 0 
secured -ws 144 -wr 1 -wn 1 -1 199.71.190.121 www_X 

www_r_J . . . d 192.168.125.2 -m 

Here are the corresponding entries for the firewall of the 
present invention: 

secured -N 123 -D RGnx -t - ntpp -a ntpp 
secured -N 456 -D RGnx -t - httpp -a httpp 

The following options are only used for debugging 
purposes, some might be disabled on production systems or 
supported in future releases: 

-n non-transparent proxy mode — only works for VDO-Live 
-U user_jiame set the user name (ftp ftp__mux and ftpp/ 

ftpd) 

-A ch set the audit method, ch=s for syslog, ch=a for audit, 

ch-e for stderr 
-m disable socket mating 
-L disable connection logging 

-z set non-paranoid mode, which relaxes IP address checks 
for UDP proxies 

Audit Issues 

The firewall of the present invention uses new structured 
audit calls for session logging, which include sre and dst 
region, ACL matched, auth method, encryption state, etc. 
The new calls are: 

audit_session_begin 

audit_session_continue 

audit_session_end 

audit_log_ftp — to log FTP file transfers, includes user, 
filename, size 

audit_log__smartfilter — to log URL, action (allow/deny), 
blocked categories 

audiL_acl_deny — to log ACL denials 
audit_ipsec_fail — to log IPSEC failures 
audit_auth_fail — to log authentication failures 

Authentication Issues 

SecureZone has incorporated the proxy-warder-interface 
(pwif) from Sidewinder. We also support external authenti- 
cation servers such as snk, safeword, securid. The pwif 
interface was already supported by tnauthp, we added pwif 
support to ftpp, and for GUI login. We are not using pwif for 
squid, instead we are using their build-in passwd file sup- 
port. The backend will have to keep the squid passwd file in 
sync with the static-passwd file used for ftp and telnet, 

ACL Issues 

Besides a simple allow/deny, the ACLs also return the 
following: from__region, to„region, destination redirects 
for IP and port, source redirects for IP and port, transparency 
settings and filters. We have standardized ACL filters as 
follows (example from acl__util.h): 
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Mcfine FIUT_DEUM 
/* 



' all filters will be at least 3-characters in length 

* proxy ACL filters will all start with "p" 

* all filters should be disabled (0) by unless ACLs enable them 
7 

/" generic proxy filters - all start with "pg" 



' filLdebug 

' fill_crypto_from 
1 fi!t_crypto__to 
' filt_crypto_levels 



" filt_loc_auth 



* filt_rem_auth 

* filt_undef_servers 



filter "pgdN" sets debug level to N 

filter "pgeR: levels" requires encryption in regions R, 
where R equals F, T, B for from_ign, to_rgn, both, 
and levels is colon delimited in "rc4-40:rc4-128:des56:3des" 
For example, pgeF:rc4-128:3des" would force strong 
encryption between the client and the firewall 

filter "pgaX" specifies local auth 

the character X gives the method: S, s, w 

for STRONG_ONLY, STRONG_PREFER, WEAK_PREFER 

TRUE or FALSE 

filter "pgA:" specifies list of remote auth methods, 
colon delimited "pgA:radius:safeword:securid»nk" 



typedef struct { 

/* generic proxy filters - see above for their defined values */ 

char filt debug; 

char filt_crypto_frorn; 
char filt_crypto_to; 

int filt crypto_levels; 

char filL_loc_auth; 

char fUt_rem auth; 

char * *fUt_undef_servers; 

/* FTP proxy alters - all start with "pf * 7 

char ait_port; /* filter "ptb" disables PORT command 7 

char fUt_j>asv; /* filter "pfa" disables PASV command 7 

char ftlt_get; /* Alter "pfgf disables RETR command 7 

char fUt_put; /* filter "pfp" disables STOR command 7 

char filt site; /* filter "pfe" disables SITE command */ 

char filt_mkdir; /* filter "pfm" disables MKD command */ 

char filt_rmdir; /* filter "pfr" disables RMD command 7 

char filt_delete; /* filter "pfd" disables DELB command */ 

char ait_rename; /* filter "pfv" disables RNFR & RISTTO commands 7 

char filLanon; /* filter "pfT disables USER ftp and anonymous 



u_long filt size; 

p__acl_filter_t; 



/* filter "pfsN" sets N KB to max file size */ 



Here are some example filter strings, from acl_load.c: 



/* FTP: site, del, WWW: java, activcx, cookies */ 
#dcfine FILTER_STR1 "pfs|pfd|pwj{pwa|pwc|" 

/* generic filter: debug»3 7 
#definc FILTER_STR2 "pgd3|" 

/■ debug = 2, FTP: 69K, strong auth, with external auth servers */ 
^define FILTER_STR3 "pgd2|pfS69|pgaS|pgA:safeword: radius)" 



SQUID Issues 55 

The caching WWW proxy (squid) is very interesting 
because it has its own ACL checks and non-blocking DNS 
interface. We leveraged this built-in support in our work, but 
il was still tricky to integrate the firewall's ACL calls while 60 
operating as a non-blocking long-lived proxy. 

Squid supports something called proxy- authentication, 
but this will only work if someone has configured their web 
browser to contact a proxy for all URLs. Before doing ACL 65 
checks, we use the following code to handle this special 
case: 



if{scc_getregion(&conn-;>me.sin_addr) == 0) 

name_valid « 1; /* non- transparent mode supports proxy-auth 7 

else 

name_valid = O, /" transparent mode does not "/ 



This will cause ACL checks for transparent HTTP 
requests to bypass user nodes, and squid will ignore auth 
filters. Non-transparent requests (where the connection is 
TO the firewall) will enforce any user codes and auth filters 
in the ACL tree. 

Since the proxy might not get an authentication filter after 
the ACLs return NEEDS_USERNAME, the squid proxy- 
auth code has been changed to not return a failure code if the 
password was not accepted. Instead we save some internal 
state, and only check this state if an authentication filter is 
returned later. 

[t is worth noting that in non-transparent mode squid can 
proxy and authenticate http, gopher, ftp and wais URLs. 

In the Proxy 

The proxy will make two calls to the ACLs. The first will 
be: 
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/* usually null */ 
/• usually null "7 
/* null if none 7 
/* tell if name is valid 



int sec is_scrvicc_allowcd( 

unsigned long service^ number, 

struct sockaddr_in "sre ip, 

struct sockaddr_in * dst_ip, 
char •src_Jiost_name, 
char 'dst^Jiosl^name, 
char *user_name, 
int name_valid, 
/* return values 7 
int &to_region; 
int &from_region; 
int &filter_texUen, 
char &fUter_text, 
int rule_name__len, 
char &rule_name, 

struct sockaddr_in &redirecL_src_addr_port, 
struct sockaddr_in &redirect_dst_addr_port, 
int &master_key, 

caddr__t &connection_id /* id for this connection 



10 



15 



20 



The possible return values will be: 
#define ACL_DENY 0 
#define ACL_ALLOW_HIDE_SRC 1 
#define ACL_ALLOW_HIDE_DST 2 
#define ACL_ALLOW_HIDE_BOTH 3 25 
#define ACL_ALLOW_SHOW^VLL 4 
#define ACL_RESOLVE_SRC_ADDR 5 
#define ACL_RESOLVE_DST_ADDR 6 
#define ACL_NEED_MORE_FILTER_SPACE 7 
#define ACL_NEED_USER_NAME 8 30 

Thus the ACLs will return, for each connection, how to 
hide the addresses. The description of each of these values 
is as follows: 

service_number: this is a number that the backend decides 
and is unique per service or possibly per service, from and 35 
to region triplet as desired. 

src_ip: this is the source IP address of the connection. 

dst_jp: this is the destination IP address of the connection. 

src_host__name: this is the host name based on the reverse 
lookup of the source address of the connection. This is 40 
generally only used when the kernel explicitly asks for it 
by returning from a previous call to scc_js_service_ 
allowed with a return value of ACL_RESOLVE_SRC_ 
ADDR. 

dst_host_name: this is the host name based on the reverse 
lookup of the destination address of the connection. This 
is generally only used when the kernel explicitly asks for 
it by returning from a previous call to scc_is_service_ 
allowed with a return value of ACL_RESOLVE_DST_ 
ADDR. 

user_name: this is the user name of the person using the 
service, Tliis value is only used when ACL__NEED_ 
USER_NAME has been returned by the kernel. Use 
NULL, if the name has not yet been requested. Currently 
only FTP, telnet and WWW support user names. 55 

name_valid: this tells the ACLs whether or not a user name 
makes any sense for this protocol. If the name_valid flag 
is set to TRUE, then user decision nodes will be used (and 
thus a user name will be required if a user decision node 
is encountered when checking the ACL). If set to false, 60 
then the user decision nodes will be ignored and the true 
path of those nodes encountered when checking the ACL 
will be used. 

to_region: the region number that the destination address of 
this connection is in. 65 

from_region: the region number that the source address of 
this connection is in. 



45 



50 



fllter_text_len: this is a pointer to an integer which has the 
length of the filter_text array in it. This value will be set 
to the amount of data returned by the access call on return. 
If the return value is ACL„NEED_MORE_FILTER_ 
SPACE, then the value in this variable will contain the 
amount of space required. 

filter text: this is an array of characters of size filter text 

len which will be used to store the concatenated filter 
strings accumulated while checking the ACLs. 

rule_name Jen: this is the size of the array rule^name. 

rule__name: this is the name of the rule that allowed or 
denied the connection. Only a maximum of rule_name_ 
len — 1 characters will be stored in there. 

redirect_dst_addr___port: this is the address and port to 
redirect this connection to. The system will set this to all 
zeroes if it is not in use. The port and address will always 
both be set together in this structure if it is to be used. 
Only the sin_port and sin__addr part of the structure will 
be used. 

redirect_src_addr__port: this is used to indicate to the 
firewall that when making the connection from the fire- 
wall to the destination, it should use the source address/ 
port provided. Note that unlike the redirect_dst_addr_ 
port field only the parts of the address required will be 
filled out. In particular, if the port is specified but not the 
address then the address field will be zero. Similarly, if the 
address is specified but not the port, then the port will be 

zero. For the redirect_dst_addr port, if one or both field 

are specified then they are both returned (with the 
unspecified field left the same as the actual destination). 

master _Jtey; this is the key that indicates which items have 
been licensed on the firewall. 

connection_id: this is the connection id for this connection. 
When the service is finished you provide this id to the 
scc_service_done system call and that function decre- 
ments the correct counters. 

Note that the user name will be used by the system to get 
the groups automatically behind the scenes in the library 
call. This means that the actual call to the kernel will have 
more fields. In particular, there will be a list of group names 
and a counter to indicate how many elements are in the list. 

The second call will be: 
int scc_service_done(caddr_t connection_id); 

This call always returns zero now. The kernel will use the 
information in the proc structure for this process to decre- 
ment the connection counts for this connection. 

There is one other call that a proxy might have to make. 
When an ACL is updated, proxies have to recheck their 
connections to see if they can still make the connection. This 
is done as follows: 



int scc_jecheck service( 

unsigned long semce_number, 

struct sockaddr in *src ip, 

struct sockaddr in *dst ip, 

char "sre host_name, 

char *dst b.ost_name, 

char *user_jianie, 

int name valid, 

caddr_t &conncction_id 
/* return values 7 
int &to_jegion; 
int &from_region; 
int &fUtei_t£xt_Jen 
char &filter_text, 
int rule_name_len, 
char &rule_name. 



/* usually null 7 

/• usually null 7 

/* null if none */ 

/* tell if name is valid */ 

/* id for this connection 7 
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-continued 

struct sockaddr_in &redirect_src_addr_port, 
struct sockaddr_in &redirect_dst_addr_port, 
int &master__key 

); 



Returns from this will be the same as for the scc_Js_ 
service_allowed call except that connection_id is passed in 
as a parameter not a return value. 

If the connection is not allowed, then the counters are 
automatically freed up and the proxy need not make any 
further calls for that connection. In the case of counter 
nodes, the recheck will fail until the counter is at an 
acceptable level. This means that, if the counter has been 
decreased below current connection levels, the first connec- 
tion rechecked will fail and so on until the current number 
of connections counter has been decremented enough. Thus, 
proxies should recheck services in order of lowest priority to 
highest priority (typically by checking the oldest sessions 
first, when that is possible). Note that short-lived proxies and 
servers started by secured cannot guarantee the order in 
which ACLs will be rechecked, since they will all get a HUP 
signal at the same time. 

Implementation of Regions 

The following new system calls were added to BSDI 3.1 
version of UNIX to support regions: 
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List of changed files: Region modifications were made to 
the following files within the BSD/OS kernel: 



s 



10 



15 



kem/uipc mbuf.c 


netpolicy/p t_dcbug. c 


kcrn/uipc syscalls.c 


nctpolicy/ptsockx 


ACL/aclscrvice.c 


netpolicy/policy.c 


netinet/ip_Jnput. c 


nctscc/ipsec.c 


netmet/in_pcb.c 


nctsec/ipsec_ah.c 


netinet/iiL_pcb.h 


nets ec/ ipsec_esp .c 


netinet/ip_icmp.c 


sys/aclkern.h 


netinet/ip_tunnel.c 


sys/audit_codcs.h 


netinet/raw__ip.c 


sys/mbuf.h 


nefoet/tcp__input.c 


sys/region.h 


netinet/udp_usrreq.c 


sys/sysctl.h 


netkey/key.c 


net/if.c 


netpoHcy/policy.h 


net/if.h 



Region Determination Processing 

20 Referring to FIG. 5, when a packet is received as shown 
in step 80, the region ID is retrieved from the network 
interface and assigned to the packet in step 82. It is deter- 
mined in step 84 whether the packet is encrypted, i.e., a 
VPN. If the packet is encrypted, processing proceeds to step 

25 86 where the VPN security association for that packet is 
retrieved. The packet is then decrypted in step 88, and the 
previously stored region ID for that packet is replaced with 
the region ID of the VPN in step 90. All further operations 
take place on the decrypted packet. 



rgnbindO 



rgnctlQ 



rrctlQ 



scc_getrcgion() 

scc_scrvicc_checks() 

scc_backcnd_acl_calls() 

scc_servLcc_done() 

scc_get_service_counts() 



allows a service on the firewall to listen for network 
connections only in the specified region. This allows us to 
have different programs listening in different regions; for 
example, a caching WWW proxy for connections from 
internal to external and a non-caching proxy from SSN to 
external. In one embodiment, network servers were modified 
to use rgnbind0 instead ofbind0, to ensure that they handled 
traffic for the correct region. 

adds, deletes, and modifies regions and sets per- region 
parameters: Members, routeT, connection refused, and ping 
response. 

sets region- to- region policy. Currently only handles network 
address translation, but could add other parameters in future, 
retrieve the region number for a given IP address 



Other changes include: 50 
initialization of region table at system startup time; 
addition of a region number to the packet header data 

structure to record the region ID for every network packet 

received; 

addition of a field to the network interface data to record 55 
which region that interface belongs to; and 

addition of a field to the VPN security association data to 
record which region the VPN is belongs to. 
Other further changes: 

In the ICMP (Internet Control Message Protocol) 
processing, if the incoming packet is an ICMP ECHO_ 60 
REQUEST (commonly known as a "ping"), check the 
region table and only respond if ping response is enabled for 
the region from which the packet came; 

In the IPSec key and policy processing code, code was 
added to record the region ID associated with keys and 65 
policy table entries, and to manipulate keys and policies on 
a region-by-region basis; 



Ordinarily, a UNIX system then checks whether the 
packet is destined for one of the firewall's IP addresses. If 
not, the packet is forwarded to the real destination. This has 
been modified in Secure OS to check that: (a) the destination 
is in the same region as the source and (b) the "router" flag 
is set for that region, as shown in steps 92 and 94. If either 
condition is not met, the packet is not forwarded, as shown 
in step 102. 

In step 96, the system looks for any socket listening for 
the incoming packet. Traditionally this match looks at 
source IP address, source IP port, destination address, and 
destination port. This has been extended in SecureOS, as 
shown in step 98, to also check the region associated with 
the packet against the region specified in the rgnbindO 
system call, to ensure that sockets receive data originating 
only from the correct region. If all conditions are met, the 
packet is forwarded in step 100; otherwise, the packet is not 
forwarded (step 102). 
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Examples of User's View of Regions: 

This example mimics the Borderware configuration of 
internal, external, and Secure Server Net (SSN): 



5 



Name 


Members 


We show 
address to 


We sec 
address from 


Rtr 


Conn Ping 


Internal 


efO Ethernet 




External 


1 


1 1 




VPN- 




SSN 








Waterloo 










External 


efl Ethernet 


Internal 




0 


0 0 






SSN 








SSN 


ef2 Ethernet 


Internal 


External 


1 


1 1 



10 



The fields are: 



Name user specified region name 

Members physical interfaces and VPN encrypted connections that 

belong to this region. 
We Show Addr the Network Address Translation configuration. This 
lb example shows that the Internal region is hidden from all 

We See Addr others, and that the SSN region is hidden from External 
From but visible to Internal 

Rtr if 1, the firewall acts as a router between members of this 

region. In this example, packets would flow between the 
Internal region and the VPN to Waterloo as if they were 
simply going through a router. 

Conn If 1, the firewall returns "connection refused" messages 

if there is no service available on the requested network 
port. Setting this to 0 on external regions can help defeat 
network scanning attacks. 

Ping Respond to network pings (ICMP ECHO- REQUEST 

packets). Again, setting to 0 on external regions can help 
defeat network scans. 



The following example shows a region of the firewall of the 35 
present invention configured to sit between two departments 
of a company and transparently filter and control network 
access between the departments. 







We show 


We see 








Name 


Members 


address to 


address from 


Rtr 


Conn 


Ping 


Service 


efO Ethernet 


Research 


Research 


1 


1 


1 


Research 


efl Ethernet 


Service 


Service 


1 


1 


1 



45 



The two regions can see each others' addresses; that is, no 
address translation is done. Nevertheless, network connec- 
tions are only allowed if an access rule on the firewall grants 
permission. 

Conclusion 

It is understood that the above description is intended to 
be illustrative, and not restrictive. Many other embodiments 
will be apparent to those of skill in the art upon reviewing 
the above description. The scope of the invention should, 
therefore, be determined with reference to the appended 
claims, along with the full scope of equivalents to which 
such claims are entitled. 

What is claimed is: 

1. A method of achieving network separation within a 
computing system having network interfaces connected to 
form a plurality of physical networks, the method compris- 
ing the steps of: 

defining a plurality of regions; 

defining a virtual private network; 
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establishing a set of security policies, wherein the set of 
security policies defines rules for communicating 
between each of the plurality of regions; 

assigning each physical network to one of the plurality of 
regions; 

assigning the virtual private network to one of the plu- 
rality of regions; and 

restricting communication between the plurality of 
regions in accordance with the set of security policies. 

2. The method according to claim 1, wherein establishing 
a set of security policies includes defining an access rule for 
communication between two regions. 

3. The method according to claim 2, wherein the access 
rule establishes permissions for use of a communication path 
between the source and destination regions. 

4. The method according to claim 2, wherein the access 
rule establishes one or more constraints on use of a com- 
munication path between the source and destination regions. 

5. The method according to claim 4, wherein the con- 
straints include an encryption requirement. 

6. The method according to claim 4, wherein the con- 
straints include an authentication requirement. 

7. The method according to claim 4, wherein the con- 
straints include a constraint from a group of constraints 
including a time of day restriction, a concurrent sessions 
restriction, connection redirection, an address restriction, a 
host name restriction and a user restriction. 

8. The method according to claim 1, wherein restricting 
communication includes routing communication between 
different regions to an application level proxy, wherein the 
application level proxy applies the set of security policies, 

9. A secure server, comprising: 
an operating system kernel; 

a plurality of network interfaces, wherein the network 
interfaces are connected to form a plurality of physical 
networks and wherein each of the plurality of network 
interfaces communicates with the operating system 
kernel; 

a virtual private network; 

a plurality of regions; and 

a security policy, wherein the security policy defines rules 
for communicating between each of the plurality of 
regions; 

wherein each of the physical networks is assigned to a 
region; 

wherein the virtual private network is assigned to a 
region; and 

wherein communication between the plurality of regions 
is restricted in accordance with the security policy. 

10. The secure server according to claim 9, wherein the 
security policy uses an access rule to restrict communication 
between two regions and wherein communication between a 
source and destination region is only allowed if an access 
rule has been defined for communication from the source 
region to the destination region. 

11. The secure server according to claim 10, wherein the 
access rule establishes permissions for use of a communi- 
cation path between the source and destination regions. 

12. The secure server according to claim 10, wherein the 
access rule establishes one or more constraints on use of a 
communication path between the source and destination 
regions. 

13. The secure server according to claim 12, wherein the 
constraints include an encryption requirement. 

14. The secure server according to claim 12, wherein the 
constraints include an authentication requirement. 
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15. The secure server according to claim 12, wherein the 
constraints include a constraint from a group of constraints 
including a time of day restriction, a concurrent sessions 
restriction, connection redirection, an address restriction, a 
host name restriction and a user restriction. 

16. The secure server according to claim 10, wherein the 
secure server further comprises an application level proxy 
and wherein communication between regions is first exam- 
ined by the application level proxy. 

17. The secure server according to claim 10, wherein the 
secure server further comprises an application level proxy 
and wherein communication between regions is first exam- 
ined by the application level proxy. 

18. In a computer system having a plurality of network 
interfaces, including a first and a second network interface, 
in which the first and second network interfaces are con- 
nected to first and second networks, respectively, a method 
of processing a packet having a source region and a desti- 
nation region, the method comprising: 

defining a plurality of regions, wherein defining includes 
assigning a first region identifier to the first network 
and a second region identifier to the second network; 

establishing a security policy, wherein the security policy 
defines rules for communicating between the plurality 
of regions; 

receiving a packet at the first network interface; 

assigning the first region identifier to the packet; 

reviewing the security policy to determine if transfer of 
the packet between the source region and the destina- 
tion region is permitted for packets assigned the first 
region identifier; and 

if so, forwarding the packet to the destination region. 

19. The method according to claim 18 wherein reviewing 
the security policy includes issuing a mgbindQ system call 
to ensure that sockets receive data only from a predefined 
region. 

20. In a computer system having a plurality of network 
interfaces, including a first and a second network interface, 
in which the first and second network interfaces are con- 
nected to first and second networks, respectively, a method 
of processing a packet having a source region and a desti- 
nation region, the method comprising: 

providing a virtual private network; 

defining a plurality of regions, wherein defining includes 
assigning a first region identifier to the first network, a 
second region identifier to the second network and a 
third region identifier to the virtual private network; 

establishing a security policy, wherein the security policy 
defines rules for communicating between the plurality 
of regions; 

receiving a packet at the first network interface; 
assigning the first region identifier to the packet; 
determining if the packet is encrypted; 
if the packet is encrypted, changing the region identifier 

assigned to the packet, wherein changing the region 

identifier includes: 

retrieving a virtual private network security association 

for the packet; 
decrypting the packet; and 

replacing the first region identifier with the third region 
identifier; 

reviewing the security policy to determine if transfer of 
the packet between the source region and the destina- 
tion region is permitted when the packet is received 
from the virtual private network; and 
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if so, forwarding the packet to the destination. 

21. The method according to claim 20 wherein reviewing 
the security policy includes issuing a mgbindO system call 
to ensure that sockets receive data only from a predefined 

5 region. 

22. A method of achieving network separation within a 
computing system having a plurality of networks, including 
a virtual private network, the method comprising the steps 
of: 

10 defining a plurality of regions; 

configuring a set of security policies, wherein the set of 
security policies defines rules for communicating 
between each of the plurality of regions; 
assigning each of the plurality of networks to one of the 
15 plurality of regions, wherein assigning includes assign- 
ing a region identifier to the virtual private network; 
and 

restricting communication between regions in accordance 
with the set of security policies. 
20 23. The method according to claim 22, wherein establish- 
ing a set of security policies includes defining an access rule 
for communication between two regions. 

24. The method according to claim 23, wherein the access 
rule establishes permissions for use of a communication path 

25 between the two regions. 

25. The method according to claim 23, wherein the access 
rule establishes one or more constraints on use of a com- 
munication path between the two regions. 

26. The method according to claim 23, wherein the 
30 constraints include a constraint from a group of constraints 

including an encryption requirement, an authentication 
requirement, a time of day restriction, a concurrent sessions 
restriction, connection redirection, an address restriction, a 
host name restriction and a user restriction. 
35 27. The method according to claim 22, wherein restricting 
communication includes routing communication between 
different regions to an application level proxy, wherein the 
application level proxy applies the set of security policies. 
28. In a computer network system having a plurality of 
40 regions and a plurality of services, including a first service, 
wherein each service defines a protocol for transferring data 
between two of the plurality of regions, and wherein each 
region includes one or more networks, a method of limiting 
transfers between regions, comprising: 
4 5 defining a to-from set, wherein the to -from set lists a 
source region and a destination region; 
associating the to-from set with the first service; 
defining a path, wherein the path includes desired options 
for limiting transfer from the source region to the 
50 destination region via the first service; 

storing information regarding the to-from set, the first 

service and the path as an access control rule; 
receiving a request to set up said first service between the 
5S source region and the destination region; 

comparing the request to the access control rule to deter- 
mine access; and 
if access is allowed, establishing the service between the 
source and destination regions. 
60 29. A method of achieving network separation within a 
computing system having network interfaces connected to 
form a plurality of physical networks, the method compris- 
ing the steps of: 

defining a plurality of regions; 
65 establishing a set of security policies, wherein the set of 
security policies defines rules for communicating 
between each of the plurality of regions; 
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assigning each physical network to one of the plurality of 

regions, wherein at least one of the regions is assigned 

two or more networks; and 
restricting communication between the plurality of 

regions in accordance with the set of security policies. 

30. The method according to claim 29, wherein establish- 
ing a set of security policies includes defining an access rule 
for communication between two regions. 

31. A secure server, comprising: 

an operating system kernel; JU secur j ty po ji cy y^cs an access rule to restrict communication 

a plurality of network interfaces, wherein the network between two regions and wherein communication between a 
interfaces are connected to form a plurality of physical source and destination region is only allowed if an access 
networks and wherein each of the plurality of network m ] e has been defined for communication from the source 
interfaces communicates with the operating system 15 reg ion to the destination region, 
kernel; 

three or more regions; and ***** 



a security policy, wherein the security policy defines rules 
for communicating between each of the plurality of 
regions; 

wherein each of the physical networks is assigned to a 
region; 

wherein at least one of the regions has two or more 

networks assigned to that region; and 
wherein communication between the plurality of regions 

is restricted in accordance with the security policy. 
32. The secure server according to claim 31, wherein the 
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PATENT NO. : 6,182,226 Bl Page 1 of 2 

DATED : January 30, 2001 

INVENTOR(S) :Reidetal. 



It is certified that error appears in the above-identified patent and that said Letters Patent is 
hereby corrected as shown below: 



Column 1, 

Line 54, after "invention" delete "is". 
Column 8, 

Line 65, after "firewall" insert -- is --. 
Column 9, 

Line 31, delete "itjust" and insert -- it just --, therefor. 
Line 43, after "calls." delete the paragraph break. 

Column 10, 

Line 16, delete "L.d" and insert -- i — d therefor. 
Column 11, 

Line 36, delete "DELB" and insert - DELE --, therefor. 
Line 40, delete "pfsN" and insert pfSN --, therefor. 

Column 14, 

Line 13, delete 'Ten — 1" and insert - len-1 --, therefor. 
Column 15, 

Line 57, delete after "VPN" delete "is". 
Column 19, 

Line 35, delete "rngbindQ" and insert -- rngbindQ therefor. 
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